|
|
|
|
|
|
|
An Overview of the Internal Application Manager Subsystem |
|
|
|
|
|
|
|
|
Developing applications for any purpose requires some ongoing understanding of how they behave at runtime in different environments. In particular, your application needs to record important transactions that occur between the user and the application. In implementing object-oriented programming, you need three objects to manage this transaction logging. Figure 14.1 shows the objects that participate in logging the transactions of the users. |
|
|
|
|
|
|
|
|
Figure 14.1.
The essential objects needed for the
Internal Application
Manager Subsystem. |
|
|
|
|
|
|
|
|
Understanding the Purpose of This Subsystem |
|
|
|
|
|
|
|
|
The Internal Application Manager Subsystem is responsible for initializing the entire application, tracking every user transaction, and terminating the application. In previous chapters, you used the module, modMain, as the starting point for initializing the application. However, a more elegant, object-oriented approach is to encapsulate the declaration of global object variables in the application controller class, CApplication. Within CApplication, you don't declare each object variable as Global, but as Public. This is because Visual Basic doesn't allow you to declare global variables within classes. Only code modules can hold global declarations. Nonetheless, object-oriented programming requires a minimal use of global variables, specifically those that aren't object variables. |
|
|
|
|
|
|
|
|
The biggest benefit of this subsystem lies in two areas: |
|
|
|
|
|
|
|
|
Troubleshooting and Customer Support |
|
|
|
|
|
|
|
|
The benefit of this subsystem to security is evident in the information contained in the log. Every add, update, delete, and read operation aimed at the database can be logged |
|
|
|
|
|
